1. Field of the Invention
The present invention relates generally to a client/server relationship, and more specifically to a client server relationship where the server drives an applet of the client after the client initiates communication.
2. Description of the Related Art
In a client server relationship, especially when dealing with a web server that utilizes the Hyper Text Transport Protocol (HTTP), the communication scheme is based on a request-response protocol. The general communication mechanism for client-server applications is provided by the Remote Procedure Call (RPC) protocol. Remote procedure calls provide a framework for implementing remote access to a system. They create a distributed computing environment that is established and controlled at the procedure level within an application. An RPC server consists of a collection of procedures that a client can call by sending an RPC request to the server along with the procedure parameters. The server will invoke the indicated procedure on behalf of the client, handing back the return value, if there is any. Thus, the caller, i.e., client, sends a call message and waits for the reply. On the server side a process is dormant awaiting the arrival of call messages. When a call message arrives, the server process extracts the procedure parameters, computes the results and sends them back in a reply message.
However, there may be situations where the server is the logical driver of the operation. One such example occurs for provisioning smart cards, such as Java Cards, where the server determines what should be loaded and invokes the card operation as needed. The Java 2 Enterprise Edition Java Servlet API provides an easy, scalable framework that could be used by a Provisioning Server to talk to a client via HTTP or HTTPS protocols. Thus, Java Applets can take advantage of full browser functionality to talk to the server and the card, which would be an ideal platform for Web-based development.
The Java Servlet framework provides a basic HTTP-based API on top of which to program applications. All HTTP requests are done either using GET or POST methods. The Java servlet framework provides methods for such requests such as doGet ( . . . ) and doPost ( . . . ). By default, both types of requests are forwarded to a processRequest ( . . . ) method. There is one shortcoming with this scheme. HTTP is a request-response protocol. Accordingly, the server always expects a request before issuing a reply with data. In case of a smart card, the card is also a command-response device. When provisioning a Java Card, the master key is located on a hardware security module (HSM) to which the server has access, but the client does not have access. Due to this configuration, the Server, the back end system, must drive the personalization process in the client, the front end system, after the client has requested the Provisioning Server to begin its work.
In light of the foregoing, it is desirable to implement a scheme for allowing a back end system to drive the front end system.